In recent years there have been numerous efforts made to provide “home” entertainment for consumer markets in a portable context for away-from-home enjoyment. This has been evidenced in a number of different styles of products. The first of these products was based upon simple LCD lights and flashing technology that embodied low yield processors from obsolete personal computer technology such as Tiger Handheld Games. Other examples include portable gaming systems such as the Nintendo Game Boy and the Sony Playstation Portable.
Since the introduction of real time interactive games which allowed multiple users on separate computers or gaming consoles (which in and of themselves are computers built specifically for the purpose of playing games), there has been a concern with content delivery and parallel processing of environmental variables in order to make certain that what one user sees on his screen matches the real time rendering of what other players of the same game see on their respective screens, whereby the game play experience is simultaneous and consistent for all participants.
Originally, this was attempted by a fixed set of maps programmed and shipped with the original game. Since those early games were written specifically for each individual computing or gaming environment, the hardware would be substantially identical and there was little or no chance that one system would outperform the other, and no clock synchronizing was necessary.
Although the active principals are still based on those algorithms, many extensions have been added, for instance—allowance of user customizable experiences, such as map creation or alteration, game configuration augmentation, penalties and rewards for specific game play, etc. More importantly, as games are now designed to allow users with non-specific or at least non-identical hardware to run the same or similar software, a shared timing code becomes necessary to prevent a faster system from running ahead in the processing of events, and to limit the speed of game play to the slower unit.
Additionally, the distinguishing lines between desktop computer, gaming console and portable implementations of both platforms is ever blurring. So now, in addition to real time gaming experiences, users desire real time interactive experiences including video and music (i.e. virtual clubs), tele and video conferencing, online collaboration and even instructional materials. Many of these implementations require delivery of content mixed in nature of medium as well as priority. Today, in a multi-player first person combat game, a user is likely to need to download a map of the virtual environment, including physical definitions such as gravity, three dimensional limitations, atmospheric density, weather patterns, landscape dynamics including hardness and elasticity of surface, ambient environmental data such as sounds for bodies of water, overhead birds or aircraft, and lighting and shadows based on natural illumination. A user will also require information about the other players or inhabitants of this virtual battlefield, fixed data such as names, team associations and physical representations, and changing information such as wielded weaponry, special abilities, level of damage, motion vector and current score. The user may also require the ability to talk to other players or listen in on their conversations for arranging team strategies or deciphering proximity. Other variables such as motion of projectiles or damaged or falling options, movement of vehicles with or without players, etc—each of these mentioned variables and numerous other items too numerous to mention have various levels of priority and bandwidth requirement.
Maps (including ambient data) tend to be large data items, but, because they can be downloaded for persistent storage or downloaded during game play, they are low priority issues and can be downloaded non-linearly if desired. Movement data, however, is miniscule in comparison and tends to be bursty in nature. Movement information tends to be critical as holds can cause hiccups in the game play, or down right stalls. Movement data must therefore be sent linearly and continually. Voice data, though much larger than movement data, is also relatively small and bursty and should also be sent linearly to insure proper continuity with game play.
The problem with current implementation is that most of this data is distributed from a single server to each active game participant and requires a high amount of available bandwidth with minimal network errors to be reliable. The two most common strategies are to supply either an off-premise server or to assign one of the active participants as the game daemon. There are advantages and disadvantages to both implementations. The Off-Premise Server forces all the clients to communicate so that game play is reasonably consistent with little opportunity for interruption or adulteration of experience by hackers or others who might partake of unethical game play strategies. The problem with Off-Premises Server is that the further the individual game player's node is from the host server, the worse game play is going to be for everyone. Using a Designated Game Daemon allows for better performance within a localized segment or even region, but allows users to interfere with the gaming or multi-media experience—perhaps even corrupt the signal with malicious code or content.
Having recognized these needs and pitfalls, it became evident that a codec for content delivery, both real time and staggered, needed to be developed. The software codec described herein satisfies that need by taking the benefits of the Off-Premises Server and Designated Game Daemon while minimizing their negative effects, and simultaneously protecting the ownership rights of the game proprietor and limiting participants to authorized players.